The present invention relates generally to systems and methods for printing color data from a computer application running on a host computer.
One challenge in color publishing is to reproduce colors the eye sees on a plurality of devices, some of which may have limited color capabilities. Even the best photographic film can capture only a small portion of the colors discernible to the human eye. A computer monitor, in turn, can display only a small fraction of those colors, and a printing press can reproduce fewer colors still.
Color Management Systems
A color management system (CMS) helps to reduce or eliminate color-matching problems and makes color portable, reliable, and predictable. A CMS is a collection of software tools designed to reconcile the different color capabilities of scanners, monitors, printers, image setters, and printing presses to ensure consistent color throughout the print production process. Ideally, this means that the colors displayed on a monitor accurately represent the colors of the final output. It also means that different applications, monitors, and operating systems will display colors consistently.
The total range of colors reproduced by a device is referred to as its “gamut.” A color is said to be “out of gamut” when its position in one device's color space cannot be directly translated into another device's color space. For example, the total range of colors that can be reproduced with ink on coated paper is greater than that for uncoated newsprint, so the total gamut for uncoated newsprint is said to be smaller than the gamut for coated stock. In addition, a typical cyan-magenta-yellow-black (CMYK) gamut is generally smaller than a typical red-green-blue (RGB) gamut.
A CMS is most beneficial when designing publications for output devices with small color gamuts, such as printing presses, proofers, and desktop printers. A CMS maps colors from a device with a large color gamut, like a monitor, to a device with a smaller color gamut, like a proofer or printing press, to ensure that all colors on the monitor represent colors that the output device can reproduce.
Before desktop publishing, high-end prepress operators used proprietary, or closed, systems, where all devices were integrated and calibrated to known values in order to work together. Color specialists were highly trained professionals who could work these systems to make a wide variety of adjustments to the color in a scanned image and predict, with reasonable accuracy, what the final printed piece would look like based on their manipulations.
Certain factors in the prepress, printing, film, and video industries have made these high-end proprietary solutions less viable. Desktop publishing has brought about the increase of open production systems. The design and production workflow is no longer confined to a closed system, but maybe distributed across many different systems made up of devices from different vendors.
Because each device reproduces color differently, the color you see at one stage of design and production rarely matches what you see at another. In other words, color is device-dependent—the color you see depends on the device producing it. A scanner interprets an image as certain RGB values according to its particular specifications; a particular monitor displays RGB colors according to the specifications of its phosphors; a color desktop printer outputs in RGB or CMYK according to its own specifications, and each press produces printed output according to the specifications followed (e.g., SWOP, TOYO, DIC, etc.) and the type of inks used.
Thus the need for an open color management system to communicate color reliably between different devices and operating systems. Open color management lets you compensate for the differences in these devices and communicate color in a device-independent manner.
Perhaps the most frustrating aspect of working with digital files for color output is that WYSIWYG (what you see is what you get) doesn't always apply. The color you work so hard to get “just right” on your monitor doesn't look nearly as right when you print it. The reason is simple.
By their very natures, a monitor and a printing press reproduce color in completely different ways. A monitor use the RGB color model. This is an additive color model where red, green, and blue light is combined to create colors, and combining full intensities of all three make white.
A conventional printing press, by contrast, uses the CMYK color model, in which three colors of transparent ink (cyan, magenta, and yellow) are combined—along with black (noted as K)—in varying amounts to create colors. CMYK is a subtractive color model where the inks filter the white light that reflects back from the paper and subtract some of the red, green, and blue light from the spectrum. The color we see is what's left in the spectrum. Subtracting all colors by combining the CMY inks at full saturation should, in theory, render black. (However, impurities in the existing CMY inks make full and equal saturation impossible; some RGB light does filter through rendering a muddy brown color. Hence, the addition of black ink to CMY.)
Moreover, RGB and CMYK have different color gamuts, or ranges of reproducible colors. RGB monitors can display more colors than can be matched in print. Conversely, some CMYK colors cannot be matched on-screen. Moreover, RGB gamuts vary widely between devices with some gamuts being considerably wider than others. While this may seem beneficial, wider RGB gamuts can be problematic when outputting to a press. The colors in the RGB gamut that are outside the CMYK gamut must be compressed (i.e., mapped to a space within the CMYK gamut). This always entails a loss to the quality of the original design and underscores the feeling that what you see is not what you get.
As explained above, color varies depending on the device which produces it. In other words, each device has its own color space. In a sense, each device speaks its own color language that it can't communicate well to another device. What's needed is an interpreter. A color management system interprets these color languages using a device-independent color model as its neutral color language by which all color information is referenced. The particular color model used is the International Committee on Illumination (CIE) 1931 2-degree standard observer, from which the CIEXYZ (1931) and CIELAB (1976) color spaces can be derived. CIE's standard for measuring color is based on how the human eye perceives it.
The color-managed workflow is fairly straightforward and possesses two major characteristics. First, images are edited in a device-independent color space which is larger than the color space of the output device, such as a computer monitor, a TV screen, film, or a four-color press. Second, image files can be saved with profiles that contain information describing the characteristics of the source and output color devices.
These two considerations make a color-managed workflow advantageous. The image files become portable since they can be repurposed for output on widely differing devices simply by tagging them with different output profiles.
The ICC Color Management Model
In 1993, members of the computer and color publishing industry began working toward a common approach to color management. They formed the International Color Consortium (ICC) in order to establish color standards that would help users achieve reliable and reproducible color throughout the entire reproduction process. They also endorsed an open framework for developing color management systems.
An ICC color management system has three major components:                A device-independent color space, also known as a Reference Color Space.        Device profiles that define the color characteristics of a particular device.        A Color Management Module (CMM) that interprets the device profiles and carries out the instructions on what to do with different device's color gamuts.        
One of the first decisions made by the ICC was to assign the responsibility for color space transformations to the operating system. Placing the responsibility there meant that color management would not have to be replicated in each application while still being available to all applications. Device color profiles (sometimes referred to simply as “profiles”), which contain information on the color behavior of the various peripherals, provide the data necessary to perform these transformations.
The ICC chose the CIE color model as the device-independent color space for color management. Since device-specific colors from any device can be mapped into a device-independent color space, it's much easier to combine equipment from different vendors into one system and maintain color specifications. Because they are well-defined and reproducible, the CIE color spaces (CIELAB and CIEXYZ) are an excellent language for communicating color information between different systems.
Device Profiles
A color management system must have available to it the characteristics of each device in the production process, namely their color “behaviors” and color gamuts. It gets this information from files called device profiles. A device profile enables the CMS to convert between a device's native color space and a device-independent reference color space (i.e., CIELAB or CIEXYZ).
Each device in the production system has its own device profile, either provided as part of the CMS, available from the device's manufacturer, or included with third party hardware, software, or both. The CMS uses these profiles to convert one device dependent color space into the device independent reference color space and then to a second device dependent color space (that of the output device).
Device profiles characterize a particular device by describing the characteristics of the color space for that device in a particular state. Some devices have only one profile, for example a monitor. Others, like printers, may have several since any changes to the printer state need to be accounted for in a separate profile.
Profiles can also be embedded within image files. Embedded profiles allow for the automatic interpretation of color information as the color image is transferred from one device to another.
Device profiles are divided into three classifications:
1. Input profiles for devices such as scanners and digital cameras (also known as source profiles).
2. Display profiles for devices such as monitors and flat panel screens.
3. Output profiles for devices such as printers, copiers, film recorders, and printing presses (also known as destination profiles).
Color Management System Workflow
FIG. 1 illustrates the concepts for matching colors from one device to another for a computer system 100. System 100 includes a monitor 102, a scanner 104, and a printer 106. When a document is scanned into scanner 104, it becomes a data set in the device-dependent color space of scanner 104. In order to view the colors of the document on monitor 102, the data set must be transformed into the color space of the monitor.
This is a two-step process. First the data set is transformed into a device-independent color space referred to as a “profile connection space” (PCS) 110, using an input profile 108 that describes the color behavior of scanner 104. Then the data in profile connection space 110 is transformed into the color space of monitor 102 using display profile 112, which describes the color behavior of monitor 102. In order to print the data, it is transformed from profile connection space 110 to the color space of printer 106 using output profile 114, which describes the color behavior of printer 106.
The Color Management Module (CMM)
The Color Management Module (CMM) is the part of the CMS that maps one gamut to another. When colors consistent with one device's gamut are displayed on a device with a different gamut, a CMM uses device profiles and rendering intents to optimize the displayed colors between the two devices. The CMM does this by mapping the out-of-gamut colors into the range of colors that can be produced by the destination device.
Each CMS has a default CMM, but may support additional CMMs as well. For example, Apple ColorSync 2.0, a CMS for the Mac OS, uses Linotype-Hell's CMM by default, but also supports other CMMs such as those in Kodak's KCMS and Agfa's FotoTune.
Rendering Intent
A CMM maps colors from one device's color space to another according to a rendering intent. The rendering intent determines the method the CMM uses for converting (i.e., mapping) colors from one device's gamut to another. The four rendering intents are perceptual, saturation, relative calorimetric, and absolute colorimetric.                Perceptual. Compresses the total gamut from one device's color space into the gamut of another device's color space. This preserves the visual relationship between colors by shrinking the entire color space and shifting all colors—including those that were in gamut.        Saturation. Reproduces the original image color saturation (vividness) when converting into the target device's color space. In this approach, the relative saturation of colors is maintained from gamut to gamut. This render intent is primarily designed for business graphics, where the exact relationship between colors (such as in a photographic image) is not as important as are bright saturated colors.        Relative Colorimetric. When a color in the current color space is out of gamut in the target color space, it is mapped to the closest possible color within the gamut of the target color space, while colors that are in gamut are not affected. Only the colors that fall outside of the destination gamut are changed. This render intent can cause two colors which appear different in the source color space to be the same in the target color space. This is called “clipping”. This is the default method of color conversion built into Adobe Inc.'s Photoshop 4.0 and earlier. The “relative” in Relative Colorimetric means that the colors are scaled relative to the paper white, i.e. that a pure white color (i.e. L*=100, a*=b*=0) is rendered as paper white on the output device.        Absolute Colorimetric. Colors match exactly with no adjustment made for white point or black point that would alter the image's brightness. Absolute colorimetric is valuable for rendering “signature colors”, those colors that are highly identified with a commercial product such as the yellow used by the Eastman Kodak Company, or the red used by the Coca-Cola Company. In Absolute Colorimetric rendering, the color of white (i.e. the color of the paper for a printer space) is preserved as much as possible on the output device. For example, a newsprint profile would have a fairly dark, slightly yellow paper color. In Absolute Colorimetric rendering, this color would be rendered in regions of the page that were white, but in Relative Colorimetric rendering, the white regions would not be marked at all.        
In a conventional color publishing system, the final step in the color publishing process is the printing run, where a printing press creates a large number of color copies of a document for distribution. The printing run is an expensive process, so it is essential that designers know what the colors on the document produced by the printing press will look like before sending it to the printing press. Designers use an emulation process referred to as “color proofing” to simulate the output of the printing press. In color proofing, a printer, referred to as a “proofing printer” is used to emulate the printing press.
Proofing printers are usually CMYK devices which try to emulate what would happen if one used the same CMYK data on another output device such as a conventional offset lithographic press. If a proofing printer had the same gamut as a printing press, the selection of the appropriate rendering intent to use would be straightforward. Unfortunately, in the world of ink-jet printers, the gamuts of devices vary widely depending on what stock is used in the printer, what mode is used to print, and other similar factors.
One approach that has been taken is to let the user decide which rendering intent to use. However, most users don't understand proper selection of rendering intents and either make an inappropriate selection or never bother to select a rendering intent at all. Another approach is for the rendering intent to be fixed in advance for use in all circumstances, thereby producing good results in some circumstances and mediocre results on others.